![]() ![]() ![]() ![]() ![]() |
Troubleshooting and Configuring the Windows NT/95 Registry
-28-System Policy Editor: Understanding Policy FilesIn an organization with tens, hundreds, or even thousands of users, the effective and efficient management of all of these Registries can be unwieldy, if not impossible. Up to this point in the book, all of the changes to the Registry have been made one system at a time. Imagine making all (or even half!) of the changes discussed in this book for 100 systems. The time to do that would be much too great. System Policy Editor allows you to make changes for all the systems on your network at one time. It also allows you to make changes to an individual system. User management is also easier with System Policy Editor. User-based changes can be made for an individual, for groups of users, or for all users on the network. These changes are made from an individual system, an NT server or a Windows 95 system, and then distributed to all the systems at logon. The changes to be made to the Registries of the systems on the network fall into four categories:
This section will introduce you to one of the most powerful ways to perform system-wide management of the Registries: the System Policy Editor. This allows you to impose updates on systems for user-level and computer-level changes. It requires no user input, and the user has no choice to accept or reject the settings, because the policy automatically overrides any changes the user makes. Understanding Policy FilesThe Latin root of policy is the same as for police (politia). Webster's Dictionary defines policy as a "high-level overall plan embracing the general goals and acceptable procedures of a government body." A policy in Windows NT or 95 is exactly the same. As an administrator, you must impose procedures and maybe even restrictions on users on the network. From the System Policy Editor in Windows NT Server 4.0, you can set policies for NT 4.0 systems only. It will not set policies for Windows 95 systems or NT 3.5x systems. The System Policy Editor in Windows 95 will only create policies for Windows 95 systems. The System Policy Editor for Windows NT is installed during the Server installation. The System Policy Editor for Windows 95 on the Windows 95 installation CD-ROM, and can be run directly from the CD or copied onto the hard disk. The menus, interface, and all functions are the same as the Policy Editor in NT, but the policy file created by the Windows 95 Policy Editor is saved in ASCII, while the policy file created by the NT Policy Editor is saved in Unicode. The two policy files are completely incompatible. The System Policy Editor in Windows 95 can create policies only for systems running Windows 95, and the System Policy Editor for NT can create policies only for NT 4.0. And, unlike Windows 95, the System Policy Editor for Windows NT also allows the use of multiple template files, making the addition of policies very simple. Even though many of the system settings for NT 4.0 are exactly the same, Windows NT 3.5x doesn't even look for a policy at logon. The existence of a policy file has no impact on NT 3.5x.
Because of their similarity, this book will deal with both editors together. Only during the template file discussion will they be separated. Any policy that you implement updates the Registry automatically at logon. Types of changes include user-specific and computer-specific changes. User-specific changes affect HKEY_USERS, and computer-specific changes update HKEY_LOCAL_COMPUTER. Examples of user-specific changes include
These settings can be implemented for a specific user, all users, or by groups (as set up in User Manager for Domains). Examples of computer-specific changes include
Computer-level policies can be set for all systems in general or for specific systems only. Policies implemented on the system override all other settings that conflict, as illustrated in Figure 28.1. For example, you could set a policy demanding that the wallpaper be the company logo. If a user changed it during a session (using Control Panel | Display | Background), the company logo would reappear as soon as he logged off and back on again. Figure 28.1. Policies override all other settings at logon.
Not all settings in the Registry are affected by the implementation of a logon script. Similarly, User Profiles do not override everything set by the Registry and the logon script. Policies have ultimate priority. Anything they change overwrites any other settings in the system. Creating a Policy FileOpen System Policy Editor in NT with Start | Programs | Administrative Tools | System Policy Editor. Start the Windows 95 editor by activating POLEDIT.EXE, which is on the Windows 95 installation CD, in the \ADMIN\APPTOOLS\POLEDIT directory. After opening the editor, select File | New Policy, and you will be presented with the screen shown in Figure 28.2. Notice that there is an icon for default computer and another for default user. Any policy settings created for the default computer automatically affect every NT 4.0 or Windows 95 system on the network. Any policy created for default user likewise affects every user on the network that is running NT 4.0 or Windows 95. Figure 28.2. System Policy Editor in Windows NT 4.0 server.
Figure 28.3. Creating a policy specifically for SERVER1, Bob, and the New Users group.
Unlike the Registry Editor, the System Policy Editor does not automatically save changes. If you do not save them, changes are lost at exit. To save the policy, select File | Save. Policy files are stored in the NETLOGON share in a Windows NT network, so all users logging on to the system have immediate access to them. The actual path to the NETLOGON share is %systemroot%\system32\Repl\import\scripts. Any changes to the NT policy are saved there as NTCONFIG.POL for NT systems. NT always looks for a policy named NTCONFIG.POL at logon. If it is not there, no change to the Registry occurs. As long as they are present, any changes activated in the policy overwrite any Registry settings, as shown in Figure 28.4. Likewise, Windows 95 looks for a policy file called CONFIG.POL in the NETLOGON share.
Figure 28.4. Policies overwrite Registry settings at logon.
If, after the change is made, the policy file is removed or the policy is no longer specified, the user can change the setting in his personal Registry without it being overwritten. Returning to the wallpaper example discussed previously, if the user changes his wallpaper and no policy maintains the setting of the logo wallpaper, the wallpaper is not changed back. Policies that restrict users should be present at all times, regardless of the preferences of the user or any change made by software. An example of such a case is the restriction on common groups. If you disable access to common groups for a particular user, that user can enable access to the groups if he knows where the Registry change is for that setting. Likewise, any Registry change that can be implemented through the Registry is a perfect candidate for a permanent policy.
After certain policies have written to the Registry, they no longer need to be in effect. An example of such a policy is one that changes IP address settings for the network: After everyone has logged on to the network, that policy need not remain in effect. Another example of such a policy is one that restricts a user from editing the Registry: The user cannot undo such a change, so there is no reason for the policy to remain in effect. If the setting can change during the session, and if the policy is no longer in place, the policy is defeated by a Registry change.
SummarySystem Policy Editor allows an administrator to effectively manage a large number of users and systems in an organization from a single location. The opportunities for the direction of change are significant and far-reaching. Used wisely, System Policy Editor can save huge amounts of time and effort in training, troubleshooting, management, standardization, and administration of a network. Used unwisely as a tool for domination and user restriction, it may cause a revolt among your users. Use caution, concern, and communication, along with training, to implement policies in your organization to meet the organization's needs and agendas. |
|